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EXHIBIT A 


REDACTED VERSION OF DOCUMENT PROPOSED 
TO BE FILED UNDER SEAL 
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Moog’s Trade Secret Identification is Sufficient Under the Transferor Court’s Order 
and the Law Governing Early Discovery Identification of Trade Secrets 


This document contains technical data as defined in the International Traffic in Arms Regulations 
“ITAR” at 22 CFR § 120.10. Such technical data may not be exported, disclosed, or transferred to 
any foreign person, as defined in the ITAR at 22 CFR § 120.16, without first complying with all 
the requirements of the ITAR (22 CFR § 120-130) including those for obtaining a specific export 
authority. Diversion contrary to U.S. law is prohibited 


Contains Technical Data as Defined in the ITAR and Subject to Legend on Cover Page 
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Skyryse itself conceded that Moog is not required to 
identify source code line-by-line 


Case 2:22-cv-09094-GW-MAR Document 194 Filed 07/12/22 Page130f15 Page ID #:3679 


Moog also argues that providing a narrative response “would require Moog to list each and 
every line of code from the tens of thousands of source code files.” (Opp. at 4.) Interrogatory No. 
1 requires no such thing. It asks Moog to identify its trade secrets, not “every single line of non- 


public source code.” (/d. at 10.) Moog cannot seriously contend that “each and every line” of its 


Citation from Skyryse’s Reply in Support of its Motion to Compel before Judge McCarthy 


Contains Technical Data as Defined in the ITAR and Subject to Legend on Cover Page 
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WeRide Corp. v. Kun Huang 
379 F. Supp. 3d 834 (N.D. Cal. 2019) 


¢ The defendant, like Skyryse, argued that “when the alleged trade secret is source code, 
the plaintiff must identify the specific code.” The court held that “this argument is wrong 
on the law.” /d. at 846. 


e “WeRide is not required to identify the specific source code to meet the reasonable 
particularity standard.” /d. 


¢ The court found the identification sufficient where “WeRide describes the functionality of 


each trade secret” and “names numerous files in its code base .. . that reflect the source 
code specific to each trade secret.” 


Contains Technical Data as Defined in the ITAR and Subject to Legend on Cover Page 
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WeRide Corp. v. Kun Huang 


379 F. Supp. 3d 


WeRide’s Trade Secret Identification 
(Naqvi Decl. Ex. 2) 


Trade Secret 9: 


While WeRide’s description for Trade Secret 9 is fully 
redacted in the publicly available identification, its 
narrative description is less than six lines, followed by 
a list of file names 


834 (N.D. Cal. 2019) 


Moog’s Non-CUI Trade Secret Identification 
(Storey Decl. Ex. D) 


Contains Technical Data as Defined in the ITAR and Subject to Legend on Cover Page 
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The most descriptive of Moog’s identifications are of substantially more detail than WeRide’s most descriptive identifications. 


wn 
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WeRide Corp. v. Kun Huang 
379 F. Supp. 3d 834 (N.D. Cal. 2019) 


WeRide’s Trade Secret Identification: Trade Secret 1 (Naqvi Decl. Ex. 2) 


Trade Section 1: WeRide’s Implementation of Sensor Fusion-Based Localization. As 
described above, a key component of “perception” is “localization,” which means that the autonomous 
vehicle must know where it is currently located. The autonomous vehicle’ s computer accomplishes 
localization (i.e. determines the vehicle’s current location) by examining inputs from various sensors 
installed on the vehicle. ls 
Certain sensors may be less reliable in certain circumstances (i.e. cameras may be less reliable in the 
dark), while other sensors may provide limited information based on how they are mounted on the 
vehicle (i.e. a radar mounted on the front of the vehicle will provide different information than a radar 
mounted on the side of the vehicle). Making sense of the mixture of inputs from these various 
sensors, and accounting for the sensors’ locations, strengths, and weaknesses, is a process referred to 
as “sensor-fusion” (because the inputs are “fused” together into a single data stream). 

Sensor-fusion is a necessary component of localization, because the vehicle must fuse the data 
from its various sensors in order to determine its current location. However, individual 
implementations of sensor-fusion, if derived independently, should differ between autonomous car 


developers, because sensor-fusion is based on multiple, independent choices. For example there is no 


single required set of sensors that must be used—different developers may choose to use cameras and 
radar and LIDAR, or just cameras and LIDAR, or even just LIDAR, and the developer's 
implementation of sensor fusion will be based on this choice of sensors. Likewise, even after sensors 
are chosen, the brand and configuration of sensors—more choices made by the developer—also 


determines the kinds of data collected, and again will impact sensor-fusion. Finally, even if 


developers (improbably) independently elected to use identical sensors configured in an identical 
manner, the sensor-fusion code should still differ according to the goals of the autonomous vehicle 
developer and the overall design of the autonomous vehicle program; for example, different prediction 
modules (which exists separately from the sensor-fusion code) will respond differently to the same 
sensor-fusion code, and thus differences in the overall code base should be reflected in differences in 
the sensor-fusion code (again, unless the entire code base was stolen wholesale). 

WeRide is not—and does not claim to be—the inventor of the concepts of localization or 
sensor-fusion. However, WeRid? is the creator of—and claims as a trade secret—the unique 
implementation of sensor fusion localization found in WeRide’s code, and used in WeRide’s 
autonomous vehicles, which is comprised 0f x 
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The code WeRide created to accomplish its unique implementation of sensor-fusion 
localization was developed using (i) the specific sensors that WeRide has chosen to mount on its 
autonomous vehicles, as well as the configuration of those sensors, and (ii) the data generated by 
WeRide’s extensive autonomous vehicle testing, using a fleet of over 20 cars over a period of many 
months. Based on its own proprietary data and experimentation, WeRide has developed unique code 
to fuse the data from the sensors on its autonomous vehicles. This code is reflected in the following 
files that can be found in WeRide’s code base: 


Contains Technical Data as Defined in the ITAR and Subject to Legend on Cover Page 


Mullin Moog’s Non-CUI Trade Secret Identification: Trade Secret 7 (Excerpts) 
(Storey Decl. Ex. D) 


Contains Technical Data as Defined in the ITAR and Subject to Legend on Cover Page 
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Moog’s Non-CUI Trade Secret Identification: Trade Secret 8 (Excerpts) 
(Storey Decl. Ex. D) 


WeRide’s most detailed 
identification contains less 
than two pages of narrative 
description before listing file 
names. Moog’s detailed 
identifications contain much 
more detail, subcategories, 
and files specifically keyed to 
each category or subcategory. 
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